SOLVED! on my test rig I tried a state-killing option that had NOT solved the problem on my live box, but on the test rig it worked. The setting is in System/Routing/Gateways, "State Killing on Gateway Failure". After changing that from the default to "Kill states using this gateway when it is down", subsequent failover events created a few arpresolve errors in the log, but within 1 second they stopped, after an entry in the log showing a state killing action:

/rc.filter_configure_sync: GW States: Killing states for dynamic down gateway: WAN_DHCP, XX.XX.XX.1

After that worked, I had to figure out why this solved the problem with my test rig but not my live box. Eventually I traced it to a setting in System/Advanced/Miscellaneous in the Gateway Monitoring Section, "Skip rules when gateway is down". In my live box, which has some traffic that needs to be routed only through a VPN, I had enabled the setting "Do not create rules when gateway is down" years ago to make sure, if the VPN was down, that pfSense wouldn't route the traffic through the non-VPN WAN. But as soon as I cleared that check box, my failover arpresolve problem went away. So apparently that setting interacts with the failover in a way that prevents the state-killing action from working properly.

Next job is to figure out a different way to kill VPN-bound traffic if the VPN is down... Googling that now.

Update, I Was never able to get this working properly, but Now that the 2.7.0 update has been released, once I updated, everything is working as expected. not sure if it was some sort of Hyper-V Driver issue, or some other bug that was fixed in this release.... just glad I can utilize my secondary internet connection better now. thanks for all the help!

@marl_scot
The networks on different interfaces must not overlapping.
And I don't know any router which is capable to route with that settings.
Maybe the ISP can give some recommendations.

Two IPs within the same subnet with the same gateway is not a real failover set up for my understanding.

If the ISP refuses to change one of the subnets your only one option might be to put a router between the ISP and pfSense and nat the traffic to a different subnet.

please see this post for way more information.

@luckyh_de said in Multi-WAN with Backup down:

So i have to prevent any Packet to the LTE-router AS Long as primary ist okay

Hi,

The failover mechanism does not allow this, you definitely need something that, which tells the firewall that the connections are alive
(minimum GW pinger ICMP traffic)

@yacud With failover and multiple tiers, it will use the Tier1 gateways until it meets the criteria of a failure (specified packet loss or latency).

Then it will route all traffic on the Tier2 gateway until Tier1 gateway is back within acceptable limits.

If you want to load balance you could set multiple gateways as Tier1 and it will split traffic between them, you can set a "weight" in the gateway options to have it balance the traffic unevenly (e.g. put 2x as much on WAN1 vs WAN2)

As far as I know, there is no way for it to know what the maximum throughput of your link is - just trying to split it evenly if you want load balancing.

probably something is triggering a restart of dpinger

Well, the part with 2 LANs and 2 WANs is quite easy.

You configure the transit network interface as defined by your second ISP. You configure e.g. 129.x.?.1/24 as a static IP on your "Public LAN". You either set the NAT mode to "Manual Outbound NAT rule generation." and set all NAT rules manually, or you set it to "Hybrid Outbound NAT rule generation" and manually add a "Do not NAT" rule for the traffic between your new LAN and WAN. This should already create the appropriate routing table entries so that incoming traffics finds your 129.x.?.1/24. What's missing to tell the outgoing traffic which gateway to use. This can e.g. be done by specifying the gateway of the second WAN interface in the "allow to any" (or whatever firewall rule you use to allow internet access) firewall rule on your "Public LAN" interface.

Regarding the public IPs for your 192.168.x.1/22: From my perspective, the clean solution would be to give them a second network interface (e.g. using VLANs) in the "Public LAN" network. This also makes it easier to separate the administrative from the public traffic, e.g. only enable SSH on the interface in 192.168.x.0/22 network.

@kiokoman said in How to prevent users from LAN to know the external local WAN IP ?:

in the 90's i remember there was this conspiracy theory that antivirus computers create viruses in order to sell antivirus software... say no more ... now that your isp know your fear it will ddos you to take your money ... big fish eat small fish !

Because amateur may be You newer come under real DDoS.

P.S. Another perfect example of new attacks vectors, that You may newer know https://www.washingtonpost.com/news/innovations/wp/2017/07/21/how-a-fish-tank-helped-hack-a-casino/

Добрый

В закладки https://docs.netgate.com/pfsense/en/latest/ Раздел "Routing and Multi-WAN"
И не забывайте на пф в General добавить явно каждому WAN-у по ДНС. Это важно.

на PfSense недавно, в этой сфере разбираюсь не очень хорошо

Коллеги.
Давайте не начинать каждый 2-й пост с "нытья" (
Как на вокзале, чес. слово, "Деньги украли, не могу 3-й год до Воронежа доехать, спасите-помогите". Просто пишите ТЗ. Этого достаточно.

@derelict did a Google search for netgear dual wan and one of the links was to this forum))) It crossed my mind that it's probably a wrong place to ask for help with my issue but I decided to give it a go anyways)